The present invention relates generally to optical communications, and more particularly, to a sustainable based cloud service embedding procedure in software-defined flexible-grid optical transport networks.
Software-Defined Network (SDN) architecture enables network programmability to support multi-vendor, multi-technology, multi-layer communications, and to offer an infrastructure as a service. Recently, efforts are going on to integrate optical transport within IP/Ethernet-based SDN architecture to leverage optical transmission benefits, such as low interference, long reach, and high capacity transmission with lower power consumption. Such a network is referred to as Optical Transport SDN. Optical transport SDN can be realized by enabling flexibility and programmability in transmission and switching network elements, such as transponders and ROADMs, management of optical channels, such as flexible-grid channel mapping, and extracting control plane intelligence from the physical hardware to the centralized controller.
FIG. 1 shows architecture for optical transport SDN in which control plane is abstracted from physical hardware of network elements and most network control and management intelligence now resides into a centralized controller. The centralized controller controls network elements using a standardized protocol, such as OpenFlow over standardized interfaces at controller and network elements. The control plane decisions present in the form of rules, actions, and policies, and network elements applies these decision based on match-action on connections. Thus, optical transport SDN partitions a network into software defined optics (SDO) and optics defined controller (ODC).
Software-defined optics consists of variable rate transponders, flexible-grid channel mapping, and colorless-directionless-contentionless-gridless (CDCG) ROADMs. Variable-rate transponder can be programmed for various modulation formats and FEC coding. Thus, transponders can offer variable transmission capacity for heterogeneous reach requirements. Flexible-grid channel mapping allows an assignment of flexible amount of spectrum to channels to achieve higher spectral efficiency by applying spectrum-efficient modulation formats and eliminating guard bands. CDCG-ROADM can be programmed to switch connections operating on any wavelength with any spectral requirement over any outgoing direction. Furthermore, connections can be added and dropped at a node without contentions. These hardware and their features establishes foundation of SDON optimization and customization capabilities.
Optics defining controller manages the network, and performs network optimization and customization to utilize flexibility of SDO. ODC functionalities are further extracted into network/compute hypervisor, operating system, network applications and database, and debugger and management planes. These planes are isolated by open standardized interfaces to allow simultaneous and rapid innovations at each layer independently. Various control plane functionalities, for example, cloud resource mapping, routing and resource allocation, protection and restoration, defragmentation, energy optimization, etc., are installed as applications and data base in the ODC. Network/compute hypervisor offers virtualization by providing isolation and sharing functions to a data plane as well as an abstract view of network and computing resources while hiding physical layer implementation details to a controller in order to optimize and simplify the network operations. Operating system offers a programmable platform for the execution of applications and hypervisors. Debugger and management plane offers access control and QoS management, while monitoring network performance, and performs fault isolation, localization, and recovery.
Recently, cloud services have gained a lot of interests since it supports applications by sharing resources within existing deployed infrastructure instead of building new ones from scratch. These days network applications are becoming more and more cloud centric, for example social networking applications, such as FaceBook, Twitter, and Google+, e-science applications, such as Large Hadron Collider, content applications, such as NetFlix, and search applications, such as Google and Baidu. Cloud applications are supported by interconnecting various computing, storage, software, and platform-oriented resources within data centers through networks. Each data center is built with the goal of optimizing the type of services offered, for example Google data center is built with the goal of efficient indexing of web pages and minimization of content search time, while Facebook data center is built to offer maximum storage for user contents and efficient management and linking of these contents within user's social group, Amazon EC2 data center is built to offer faster computing time. Thus, one data center may not provide all types of resource, and may not optimally meet all the requirements of a cloud application. Furthermore, failures of any data center, any fiber, or even a ROADM node on which the cloud service is currently active may terminate the entire service. Thus, cloud services must be provisioned with resiliency for computing and network resources.
In such scenarios, open challenges are how to map a cloud request among data centers offering heterogeneous resources, and how to establish network connectivity between data centers. The problem is referred to as cloud service embedding problem. In this invention, we investigate cloud service embedding problem over software-defined flexible grid transport SDN networks. The problem is formally defined as follow.
We are given a physical network topology G(N, L), where N represents a set of physical nodes (PNs) and L represents a set of physical links (PLs) interconnecting physical nodes. Each node offers different types resources, for example, 1, 2, 3, . . . , n, and the number of offered resources Cjn for each type j is given in advance. A node also consists of CDCG-ROADMs and variable rate transponders. CDCG-ROADM offers switching of flex-grid optical connections while variable rate transponders offer a set of modulation formats M, where the spectral efficiency Zm bit/second/Hz and transmission reach Dm Km of each modulation format m is also given. A fiber offers total T THz of spectrum. A cloud demand is defined as G′(V, E, C, L), where V is a set of virtual nodes (VNs), E is a set of virtual links (VLs) connecting virtual nodes, C is a set of requested resources (Ci1, Ci2, . . . , Cin) at each virtual node i, L is a set of requested line rate lij between virtual nodes i and j. The arrival and departure distributions of cloud requests are given. The problem is how to map working and backup virtual nodes of a cloud demand over physical nodes (the survivable virtual node embedding problem) and working and backup virtual links of a cloud demand over physical links (the survivable virtual link embedding problem), such that the number of embedded cloud demands is maximized. The survivable virtual link embedding problem consists of sub-problems such as how to route working and backup virtual links over physical node-disjoint routes, how to assign wavelengths and allocate spectrum, and how to select modulation formats. It is assumed that a network does not support wavelength, spectrum, or modulation format conversion capability. On the other hand, the survivable virtual node embedding problem needs to map working and backup virtual nodes over distinct physical nodes.
Survivable cloud embedding mainly consists of survivable virtual node embedding and survivable virtual link embedding. Since physical node and link resources are shared among multiple could demands, an embedding procedure needs to ensure isolation of these resources while maintaining the resource capacity constraints. When mapping working and backup virtual nodes over physical nodes, a procedure needs to ensure that different working/backup virtual nodes cannot be mapped over the same physical node. Furthermore, any working and any backup nodes cannot be mapped on the same physical node. When mapping working and backup virtual links over physical routes through optical channels in flex-grid transport SDN, a procedure needs to ensure the wavelength continuity, and spectral continuity, spectral conflict constraints. The wavelength continuity constraint is defined as an allocation of spectrum at the same operating wavelength on all links along the route of an optical channel. The spectral continuity constraint is defined as an allocation of the same amount of spectrum on all links along the route of an optical channel. The spectral conflict constraint is defined as an allocation of non-overlapping spectrum to all channels routed through the same fiber. Furthermore, a procedure also needs to make sure that a selection of modulation format for a virtual link must support at least the physical distance of the physical route on which the virtual link is mapped. The constraint is referred to as the reachability constraint. The physical routers on which working and backup virtual links are mapped must be node-disjoint to ensure the resiliency in case of failures of data centers, ROADMs, or fibers.
There have been proposed several procedures for survivable virtual network mapping problem in IP networks, but these solutions cannot be directly applicable for software-defined flexible-grid optical transport networks due to the additional optical physics-oriented constraints. One proposal introduces the concept of content connectivity, and propose the ILP formulations for providing the survivable content connectivity in fixed-grid optical networks. However, the solution cannot be applicable to flexible-grid optical transport networks due to the additional spectral continuity and spectral conflict constraints. Similarly, another attempt proposes a procedure for mapping cloud demands over fixed-grid optical networks. Yet other solutions do not consider the issues related to the flexible selection of modulation formats and spectrum allocation as in flex-grid optical networks. Additionally, the solutions only consider a single link failure scenario.
None of the attempts heretofore provide for a cloud demand that is provisioned with the dedicated protection against any single link or node failure. The present invention provides the first ever solution for the survivable cloud service embedding problem.